home *** CD-ROM | disk | FTP | other *** search
/ Magnum One / Magnum One (Mid-American Digital) (Disc Manufacturing).iso / d8 / xmodem31.arc / XMODEM.DOC < prev    next >
Text File  |  1991-01-10  |  7KB  |  165 lines
  1.  
  2.  
  3. /*
  4.  *
  5.  *
  6.  *            XMODEM.EXE
  7.  *            Version 3.1
  8.  *            ----------
  9.  *
  10.  *
  11.  * This is a special implementation of the XMODEM protocol transfer. It runs
  12.  * "beneath" Crosstalk, and in invoked via the Crosstalk "RUN" command.
  13.  *
  14.  * CHANGES IN REVERSE ORDER:
  15.  * ------- -- ------- -----
  16.  *
  17.  * 7/10/85 - While preparing v3.0, we broke the CRC routines. They
  18.  *         have been fixed. ANY v3.0 COPIES THAT ARE FLOATING
  19.  *         AROUND HAVE BAD CRC CODE! DESTROY THEM!
  20.  *
  21.  *         Moral: If it ain't broke, don't fix it.
  22.  *
  23.  * 6/29/85 - Added commline I/O error checking. Overrun, Framing, and
  24.  * v 3.0     Parity errors cause bad block. In short, we're no longer
  25.  *         relying only on checksum or CRC. Don't ask me how you
  26.  *         can get a Parity Error when you're running 8N1...
  27.  *
  28.  *         Pulled initial purge of commline chars. While this is
  29.  *         exceedingly safe, it is a pain in the neck 'cause it
  30.  *         swallows the first NAK. Things go quicker this way.
  31.  *         This also gives a greater chance of catching the other
  32.  *         side's "C" CRC request and thus enabling CRC checking.
  33.  *
  34.  * 6/24/85 - Fixed RS232 support routines (assembler) to stay in
  35.  * v 2.1     IRQ loop until IIR shows no more interrupts pending.
  36.  *         See rather lengthy explanation below.
  37.  *
  38.  * 3/03/85 - Initial version.
  39.  *
  40.  *
  41.  * HISTORY:
  42.  * --------
  43.  *
  44.  * Crosstalk STILL doesn't work right with XMODEM, especially sending files
  45.  * (Crosstalk's XX command). And neither the send nor the receive (RX)
  46.  * commands recognize the CRC option, which would greatly improve reliability.
  47.  * So this stand-alone version of XMODEM was developed as an add-on Crosstalk
  48.  * command. It uses CRC if the other side can support it, else uses the
  49.  * usual 8-bit checksum.
  50.  *
  51.  *
  52.  * USE:
  53.  * ----
  54.  *
  55.  *    1) While online to the remote system via Crosstalk terminal mode,
  56.  *     start the other XMODEM transfer, just as you would do in preparation
  57.  *     for using Crosstalk's RX or XX commands.
  58.  *
  59.  *    2) Get to Crosstalk's COMMAND? prompt (via ESC or whatever key you've
  60.  *     set up as the ATtention key).
  61.  *
  62.  *    3) Use the Crosstalk RUN command to run this XMODEM to actually do the
  63.  *     file transfer:
  64.  *
  65.  *        RUn xmodem 1 s foo        (send "foo" using port 1)
  66.  *        RUn xmodem 1 r b:xyz        (receive "b:xyz" using port 1)
  67.  *        RUn xmodem 2 r xmodem.c     (receive "xmodem.c" using port 2)
  68.  *
  69.  *    4) As the transfer proceeds, you will see status messages on your screen.
  70.  *
  71.  *    5) When the transfer is complete, you will be returned to Crosstalk.
  72.  *
  73.  * Things are made easier if you put the invariant part of the command into
  74.  * a function key within Crosstalk. Mine are set up as follows:
  75.  *
  76.  *    FK 1 "@RUn c:xmodem 1 s "        (F1 = send a file)
  77.  *    FK 2 "@RUn c:xmodem 1 r "        (F2 = receive a file)
  78.  *
  79.  * Then you just have to fill in the filename. From within Crosstalk all I
  80.  * have to do to receive "foo.exe", for instance, is press:
  81.  *
  82.  *    <F2>foo.exe<RETURN>
  83.  *
  84.  * which Crosstalk translates into a DOS command of C:XMODEM 1 R FOO.EXE
  85.  *
  86.  *
  87.  * RECOMMENDATIONS:
  88.  * ---------------
  89.  *
  90.  * When you use the RUN command within Crosstalk, DOS has to load
  91.  * TWO programs - COMMAND.COM and the one that you're RUNning. So
  92.  * I strongly recommend that both COMMAND.COM and XMODEM.EXE reside on
  93.  * ramdisk. Things really move when it's set up like that, and can be
  94.  * rather pokey (thanks to DOS' file-opening code) if not.
  95.  *
  96.  * Maybe someday Crosstalk will have a cleaner interface to external
  97.  * programs than this RUN thing. On my system I have XMODEM, KERMIT,
  98.  * COMPUSERVE and MNP protocols, all implemented via this RUN thing.
  99.  * And each time I drop into one of them, I have to wait the second
  100.  * or so that it takes DOS to load COMMAND.COM and the program itself
  101.  * from my ramdisk. Are you listening, Microstuf???
  102.  *
  103.  *
  104.  * CAVEATS:
  105.  * -------
  106.  *
  107.  * NOTE: Do not - repeat DO NOT - attempt to run this as a stand-alone transfer
  108.  * program (i.e. - outside of Crosstalk). It has some very touchy and difficult
  109.  * code that was specially developed just to allow "re-using" the serial port
  110.  * without actually opening it. This program wants to use the same baud rate and
  111.  * data structure that Crosstalk has already set up. So it doesn't set these.
  112.  * It just (CAREFULLY) massages the 8250 and 8259 so that while this program
  113.  * is running it has full input AND output interrupt-driven access to the port,
  114.  * without disturbing the environment (hardware/software) set up by Crosstalk.
  115.  *
  116.  * If you run this without first having "opened" the serial port (by running
  117.  * Crosstalk etc), then the 8250 will very likely go haywire.
  118.  *
  119.  * Just don't.
  120.  *
  121.  *
  122.  *                - Joan Riff,  3 March 1985
  123.  *
  124.  *
  125.  * 6/24/85 - Version 2.1 Notes:
  126.  * ===========================
  127.  *
  128.  * Bob Baumann found a very subtle but fatal feature of the Hayes
  129.  * 1200b internal modem. Unlike a standard 8250, the one on the
  130.  * 1200b DOES NOT present one and only one IIR value per IRQ. Instead,
  131.  * it presents the next-lower-priority IIR value AT THE VERY INSTANT
  132.  * THAT THE CAUSE OF THE FIRST IS CLEARED BY THE IRQ ROUTINE. And
  133.  * I do mean the very instant (like between instructions). We haven't
  134.  * pulled a 1200b apart to see what's tied to the IIR bits, but it
  135.  * looks like their 8250 is specially hooked to their modem, so
  136.  * that the thing can present up to 4 separate "interrupts" per one
  137.  * PC IRQ.
  138.  *
  139.  * I have heard from 1200b users who reported unspecified "problems"
  140.  * using this program under Crosstalk. No wonder! If the 1200b gets
  141.  * a parity error while receiving characters, for example,
  142.  * then its 8250 will do one IRQ for the LSR, AND THEN IMMEDIATELY
  143.  * PRESENT AN IIR FOR THE RECEIVED CHAR. Until that "received data
  144.  * available" state is cleared, the 8250 stays in the interrupted
  145.  * state.
  146.  *
  147.  * Standard 8250's (i.e. - all that I've seen except for Hayes') will
  148.  * issue a second IRQ for the second condition.
  149.  *
  150.  * There are many IIR combinations that cause a fatal lockup of the
  151.  * 8250 when used the way Hayes is using it. Thus neither XMODEM.EXE
  152.  * nor Crosstalk can get chars in or out of the 8250. Only solution
  153.  * was to exit Crosstalk and restart it (so that it would init the
  154.  * 8250).
  155.  *
  156.  * The RS232 interface code has been changed in release 2.1 to
  157.  * expect more than 1 IIR value per IRQ. This solves the problem.
  158.  * Why fight it? So much for clean, interrupt-driven code. Sigh...
  159.  *
  160.  *
  161.  *                - Joan Riff   6/24/85
  162.  *
  163.  */
  164.  
  165.